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ABSTRACT 



This thesis supports the Naval Postgraduate School's (NPS) program to develop 
a multimedia (text, voice, graphics) command and control (C2) workstation as a 
Decision Support System to aid players of the Research, Evaluation, and Systems 
Analysis (RES A) facility. RES A is a Naval wargame that focuses on the battle 
group/force level operations and command and control decision-making. NPS will 
interface this workstation with the wargame to provide players the capability to access 
and analyze game data in order to improve their decision-making ability. The objective 
of this thesis is to design a data base for the C2 workstation using data extracted from 
the game blackboard. The design will consist of a Semantic Data Model for the logical 
representation of the data and a relational data base design implemented on the 
ORACLE Data Base Management System (DBMS). This design provides a detailed 
specification of the data base structure and is intended to be used during 
implementation of the DBMS on the workstation. 
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I. INTRODUCTION 



A. THE MOVE TO DISTRIBUTED COMPUTING 

Over the past 15 to 20 years there has been a continuous and steady increase in 
the development of distributed computer systems. It is generally agreed this was made 
possible due to the recent advances in very large scale integration technology and the 
development of effective communications over local and wide area networks. It is now 
possible to purchase computer systems, which outperform the mainframes of the 1960's 
for just a fraction of their original cost. 

Although technology made distributed computing possible, it is the people and 
organizations that need the system and service it provides. As organizations expand, 
they tend to become decentralized. Distributed computing is extremely well suited to 
companies exhibiting this structure. Distributed computing represents a more natural 
realization then a system built around a single large processor because it provides the 
organization functional separability and a nonuniform distribution of the database 
[Ref. 1: p. 24]. In addition, it potentially oilers the user increased reliability, resource 
sharing, extensibility, and overall better performance. [Ref. 2: pp. 141-142] 

This move towards distributed computing may be interpreted that service to the 
user is becoming more important than hardware utilization. [Ref. 1: p. 38]. Most 
people are not familiar with computer hardware and software. Their only real interest 
is in using the computer as a tool in the performance of their job. How useful the tool 
is depends on the capabilities of the system and processors available. [Ref. 3: p. 38] 

Todays high performance, 16-bit microprocessors come close to achieving the 
performance of minicomputers. In comparison to general purpose microprocessors they 
have vastly improved memory space, the ability to handle a greater variety of data, 
powerful arithmetic capabilities, and increased speed of operation. With such 
capability, operating systems are being designed to run on microprocessors to provide 
the user with graphic displays, digitized voice, windowing capability, electronic-mail, 
and many other features. Microprocessors that can support these features, or some 
combination, are sometimes referred to as multimedia workstations. It is this type of 
workstation the Navy is trying to develop to enhance existing command and control 
(C2) systems. [Refs. 4,5: pp. 1, 11] 
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B. PROBLEM STATEMENT 



Demands on current Navy C2 systems are constantly increasing due to the 
continuing advances in technology; weapons, surveillance and detection systems. This 
in turn increases the amount and variety of data C2 systems must handle. How easily 
this data is accessed, how quickly, and the way the data is presented, directly affects 
how well the system performs, or more explicitly, how well the C2 system assists the 
commander in making a decision. 

In order to better support the commander, the man-machine interface on the C2 
workstation must be more natural and efficient, readily adaptable to individual users, 
and able to support multimedia information. Yet, the Navy's current C2 workstations 
only operate with a single system and require specialized training. What they need is a 
workstation 

flexible enough to work with a wide varietv of C2 svstems: and adaptable enough 
to meet the requirements of a diverse set 'of users.' (with) .... Both voice and 
keyboard natural language interfaces (Ref. 4: p. 1]. 

The payoff from such a generic C2 multimedia workstation is a more robust approach 
to distributed command and control. [Ref. 4: p. 1] 

The Naval Postgraduate School (NPS) is currently investigating the use of a 
generic C2 workstation as a Decision Support System to aid players of the Research. 
Evaluation, and Systems Analysis (RES A) facility [Ref. 6: p. 1]. This is part of the 
Office of Naval Technology program NO2CRC32S10 which is a research program in 
distributed command and control. RESA is a computer-based, large-scale wargame 
simulation of the Naval warfare environment [Ref. 7: p. 1.6]. It focuses on battle 
group' force level operations and command and control decision making. The Naval 
Ocean Systems Center (NOSC) has chosen the SUN microsystems' version of the 
UNIX operating system along with the Relational Data Base Management System 
ORACLE to function as the C2 workstation. 1 NPS intends to interface this 
workstation with the RESA w r argame to provide players the capability of real-time data 
extraction, via a natural language, in order to enhance their decision making abilities. 



Additional information on the Sun microsystem, UNIX, and ORACLE is 
provided in Appendix A and B. 
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This arrangement allows the RESA players, umpires, or analysts, to have access 
to organized data at nearly the same time it is generated in the RESA system. Real 
time access to data involving the current tactical situation permits players to analyze 
this data to improve the quality of their next decision or action in the wargame. It 
should help players favorably control the outcome of events by reducing the number of 
bad decisions. Data made available by this system allows umpires to identify trends, 
preclude misapplication of gaming rules, and in the process to better control the game. 
In the analysis phase, this workstation provides data which has been obtained in 
several wargame scenarios to research problems on individual components or weapon 
systems, and to study command and control relationships in Naval and Joint Tactical 
Operations. 

Installing this workstation is only the first step in NPS's program. There are 
plans to interface existing HP 9020 workstations onto the Sun/RESA local area 
network to allow additional users to access the wargame data base and to function as 
independent command nodes. The long term goal at NPS is to access the Defense Data 
Network (DDN) and provide connectivity to the RESA facility located at NOSC, San 
Diego, Ca. This connectivity will allow the study of a class of C2 problems concerning 
coordination at the headquarters level. In the Navy context, this allows researchers to 
study problems associated with ship-to-ship distributed command and control and to 
apply large computing systems to these problems in real time. 

C. STRUCTURE OF THE C2 WORKSTATION 

The overall structure of the workstation is shown in Figure 1.1 and depicts the 
basic modules required to interface the workstation with the wargame, access the data 
base, and provide the desired natural language interfaces. Module A is the only part of 
the system that presently exists except for the voice interface. This is being built at 
Standford Research Institute, Incorporated. The menu selection module is a proposed 
interim solution until a sufficient natural language module can be designed for the 
system. This would allow the user to interact with the computer by using the same 
language structure as when talking to another person. However, true natural language 
systems are still in their infancy. They require high levels of vocabulary and syntax 
flexibility, while menu-based systems require less computer memory and appear to be 
well suited for command and control queries [Ref. 8]. The Naval Ocean Systems 
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Figure 1.1 Concept of a C2 workstation as a DSS. 

Center (XOSC) identified the need for the ORACLE, RESA interface module." They 
have already written the program to extract the data from the RESA wargame, but it 
will be necessary to reformat the data to make it compatible with ORACLE. After 
reviewing this structure, the next logical step in implementing this workstation is to 
develop the ORACLE data base module. The structure and content of the data base 
must be developed before the rest of the modules can be completed. 

D. PURPOSE 

The purpose of this thesis is to design a data base for the SUN Workstation in 
support of RESA. The design will include a Semantic Data Model (SDM), which is a 
logical description of the data, and a Relational Data Base Design, appropriate for 
implementing on the ORACLE DBMS. In addition, several sample queries, using 
ORACLE'S SQL query language will be constructed to illustrate the types of 
information the user will be able to extract from the data base. 



NOSC. 



This information was provided via a phone conversation between the author and 
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E. SCOPE OF WORK 

The thesis is structured as follows. Chapter II describes the components of a 
Decision Support System and a Data Base Management System and how they can be 
used to support C2 systems. Data base processing is the main focus of Chapter III 
and IV. Chapter III describes the terminology and procedures used to create a 
Semantic Data Model (SDM). The purpose, characteristics and benefits of the SDM 
are discussed in detail. The SDM is created for the C2 workstation using data received 
from the Naval Ocean Systems Center in San Diego, CA. A portion of this schema is 
described to illustrate the concepts of SDM. Chapter IV identifies characteristics of a 
Relational Data Base Design, its format and then describes the relational design 
developed for the C2 workstation. Sample queries on the data base are provided at the 
end of Chapter IV in order to tie both the SDM and relational data base design 
together. This is followed by recommendations and conclusions for continued work in 
this area. Appendices contain information on the Sun Workstation, ORACLE DBMS, 
the data provided by NOSC, and the complete Semantic Data Model for the C2 
workstation. This work does not include implementing the relational data base design 
using ORACLE. 
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II. BACKGROUND 



Chapter II provides background information on the structure of Decision 
Support Systems and Data Base Management Systems. It defines both of these systems 
and describes their individual components, characteristics, and capabilities. In addition, 
Decision Support Systems are described in relation to their potential to improve the 
current comand and control decision-making process. 

A, DECISION SUPPORT SYSTEM (DSS) 

1. What is a DSS? 

As previously mentioned, the Navy is developing a C2 workstation as a 
Decision Support System to aid players of the RESA war game. Such a system 
provides the potential for players to use information by filtering, analyzing data, and 
comparing alternatives [Ref. 9: p. 9], It will help them make decisions concerning their 
next move in the game by considering "what if' situations. This is exactly what a DSS 
is supposed to do. 

a. Definition 

A DSS is a computer-based, online, interactive system that helps 
commanders make key decisions, thereby improving the effectiveness of their problem 
solving process. It incorporates the experience and instinct of the decision-maker to 
analyze hypothetical questions before implementing an irrevocable decision. 
[Refs. 10,11: pp. 24. 4] 

b. Components of a DSS 

DSSs are characterized as localized, autonomous systems containing 
analytical modules having free access to information. They generally consist of a data 
base management system (DBMS), report generator, a data base query language, 
graphics package, and special-purpose software [Ref. 10: p. 24]. Conceptually, this 
breaks down into four basic modules (Figure 2.1): [Ref. 11: pp. 10-13] 

1. Control - this is the user- interface or front-end of the svstem. It is usuallv menu- 
driven with kevboard inputs and interfaces with the' other three modules. It 
provides promp'ts and messages to guide the user in formatting the problem and 
generating a response. 

2. Data storage - contains all data required by the DSS. 

3. Data manipulation - this is responsible for retrieving data from the data storage 
module and producing reports or graphs using the data. It is supported by~a 
nonprocedural query language normally provided by the DBMS. 
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4. Model-building - utilizes optimizing modeling principles, statistical analysis, 
forecasting algorithms, decision analysis methods, and simulation principles' for 
modeling and~simulation purposes. 

These four modules must also display certain characteristics to be considered a true 
DSS. 




Figure 2.1 Component modules of a DSS. 



c. Characteristics 

Generally speaking, a particular system is only considered a DSS if it 
provides interactive support for the thought processes of one or more decision-makers. 
Systems used in this way must exhibit certain characteristics. Among these are: 
[Refs. 12,13: pp. 15, 77-78] 

1. Flexibilty - a DSS must accommodate and support decisions, under highly 
varying conditions, on an "ad-hoc" basis. 

2. User-friendliness - the system is tvpicallv designed for a user unfamiliar with 
computers. If necessary, it can guide users in operating the system. 

3. Natural language capability - DSSs must communicate in terms familiar to the 
user. 

4. Timeliness - speed of response is necessary to maintain continuity of the user's 
own thought processes. 

5. Enhanced decision-making - a DSS must exhibit a structure which is 
understood by the user ancf reflects his own way of thinking. 



s 



14 



6. DSS must be evolutionary - the system must evolve, grow and be easily and 
quickly modified to meet changing circumstances. 

These characteristics are the ideals or norms of the DSS concept. They are necessary 

for handling a variety of problems a decision-maker may encounter. 

2. Technical Capabilities of DSSs 
a. Functions 

The primary function of a DSS is to assist decision makers in solving "what 
if' type questions. These consist of unstructured or semi- structured problems related to 
strategic planning, management or operational control [Ref. 14: p. 8]. Unstructured 
problems are those activities in which the solution objectives are ambiguous, 
numerous, and the process required to achieve a solution cannot be specified in 
advance. It is an activity involving a decision process which is partly routine and 
partly judgmental. Whereas the routine part can be automated in a computer program, 
the judgmental aspect is the responsibility of the decision-maker. [Refs. 11,12: pp. 7, 
15] 

Goal seeking is another major contribution offered by a DSS. By 
assembling appropriate analytical and simulation models on the system, the decision- 
maker can pick a desired goal. The DSS then seeks the optimal decision path or set of 
solutions to arrive at the specified outcome. [Ref. 10: p. 25] 

DSSs also perform two other functions for the decision-maker. First, it 
allows users to manage very large data bases, where the manager may have difficulty in 
accessing and making conceptual use of all the information. 

Determining where to look for a particular piece of information is a nontrivial 
issue. Actuallv retrieving it can be a substantial task which complicates and slows 
the process of command decision [Ref. 15: p. 29]. 

DSSs reduces this problem by offering real-time data extraction and data manipulation 
or computation in order to arrive at a solution or suggested alternative. The second 
function a DSS provides is the ability to handle time-sensitive issues. These issues are 
especially common on the battlefield. As new technology is introduced to the 
battlefield, the critical response times required for decisions grow shorter at all levels of 
the command hierarchy. The human elements of the system are not able to respond 
fast enough and require some form of automation to assist in their analysis of data and 
other environmental factors. [Ref. 15: p. 28] DSSs provide this capability and offer the 
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commander the opportunity to review the problem and choose an acceptable solution 
in time to meet the immediate threat. DSSs provide this automation for the decision- 
maker, thereby reducing the time required to make a decision. [Ref. 11: p. 7] 
b. Levels of Support 

There are four levels of support available from a DSS [Ref. 11: p. 9]. These 
areas were briefly discussed throughout the beginning of this chapter and are 
summarized here as part of the capabilities provided by the system. They are: 

1. Access to facts or information retrieval. 

2. Addition of filters to selectively ask for information and give conceptual 
meaning to data. 

3. Ability to perform simple computations, comparisons, and projections. 

4. Development of useful models designed to provide the decision-maker with 
answers they can and will act on. 

These functions and capabilities are the reasons why DSS are being developed to assist 
command and control (C2) systems. 

3. Command and Control DSSs 

To understand why DSSs are being used in C2 systems it is necessary to 
understand the C2 decision making process. According to Joel S. Lawson, this process 
consists of five phases: sense, process, compare, decide, and act. The process, compare, 
and decide phase is where a DSS will be able to help improve the present capabilities 
of C2 systems. The process function extracts meaning from the signals it receives from 
the sensors and then generates event and status reports in its assessment of the 
situation. The compare function evaluates the options by comparing the local 
environment as seen from the status reports to some other desired state. Based upon 
this comparison, the decide function then determines what should be done in order to 
achieve the desired state or goal. [Ref. 16: pp. 24-25] 

A DSS is very similiar to the C2 decision making process. The system allows 
quick access to facts and information and filters and displays the information in a 
representative form (graphics and charts) that give conceptual meaning to the data. 
This is like Lawson's process function. The systems ability to assist the decision maker 
in solving "what if' type questions is equavilent to Lawson's compare function, while 
"goal seeking" is more comparable to Lawson's decide function. The advantage 
command and control DSS offers the commander is the ability to handle a wide range 
of problems under varying time constraints. It is this very need for accurate data, and 
fast and timely decisions in a very violatile and uncertain environment that provides 
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the justification for DSSs. [Ref. 14: p. 11] However, in order for a DSS to provide the 
commander non-routine information through "ad-hoc" queries, the system must have a 
suitable data base management system [Ref. 11: p. 6]. 

B. DATA BASE MANAGEMENT SYSTEMS 

1. Basic Terminology 

In order to discuss a Data Base Management System (DBMS) it is necessary 
to define some basic terms and concepts: A Data item, which is also called a field or 
attribute, is a group of non-random symbols that represent quantities, actions, things, 
facts, concepts or instructions. A File is a collection of related records and a Data Base 
is a collection of files logically related in such a way as to improve access to data. A 
Data Base Management System is a software system capable of supporting and 
managing an integrated data base. Finally, a Conceptual Model or data model is a 
logical representation of the information (data that has been processed and presented) 
contained in the data base. [Refs. 17,18: pp. 5, 3] 

2. What is a Data Base Management System? 
a. Definition 

A data base management system is a complex, usually large program that 
acts as a data librarian which stores and retrieves data from a data base [Ref. 19: p. 3]. 
Its most attractive feature is its collection of integrated, shareable, and nonredundant 
data. An integrated data base brings together a variety of data which can be accessed 
by more than one user. This ability to share data keeps the amount of redundant 
storage to a minimum. [Ref. 17: p. 5] Simply put, a DBMS is software consisting of a 
set of tools or features to manipulate and support the data base. The fundamental 
features provided by a DBMS are: [Ref. 18: p. 4] 

1. Centralized control of the data, which implies reduction of data redundancv, 
shared data, protection of the data base integrity, and enforcement of standards.' 

2. Data independence: the abilitv to modify the data base structure without 
having to modify the programs which use the data. 

3. Provision for complex file structures and access paths, such that relevant 
relationships between data units can be expressed in a natural form. 

4. Generalized facilities for storage, modification, reorganization, analysis and 
retrieval of data. This is done with programming languages, a user querv 
language or both. 

5. Security to prevent unauthorized access to stored data. 

6. Mechanisms to enable easy recovery or restoration of the data base. 
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3. Organization 

The data base organization can be visualized as three separate realms, as seen 
in Figure 2.2 [Ref. 17: pp.16-17]. The conceptual level is independent of computer 
hardware. It is a picture of the data base as visualized by the user of the DBMS. There 
are currently three main types of conceptual data base models available. They are: 
[Ref 19: pp. 117, 120, 196] 

1. Hierarchic - the structure is in the form of a tree with a one-to-many 
relationship among records. An individual record (node) may only have one 
owner (parent). It is a subset of network. 

2. Network - is a collection of records exhibiting either a one-to-manv or many-to- 
manv relationship among records. An individual record may have more than 
one parent. 

3. Relational - represented in the format of a table called a relation. Rows of the 
table are file records or tuples and fields of the relations are shown in the 
columns called attributes. 

These models describe the structure and processing of the data base. 

The logical level is the equivalent model of the user's view of the data but it is 
organized in accordance with a particular data base system model, ie. hierarchy, 
inverted hierarchy, network or relational DBMS. The final level is the physical data 
base structure realm which represents all data definition directories, access paths and 
methods, and the actual data itself. 

4. Composition 

The actual composition of a DBMS depends on the vendor. Larger computers 
can support more elaborate DBMS providing a greater variety of tools. Smaller 
systems, like microcomputers, restrict the size of DBMS and therefore, reduce the 
number of tools available. However, there are two major features common to all 
DBMS. They are the Data Definition Language (DDL) and the Data Manipulation 
Language (DML). [Ref. 19: p. 191] 

DDL is a vocabulary for describing the "schema" and "subschema." The 
schema is the description of the complete logical data base, and the subschema is the 
description of a subset of that data base used by an individual computer program. The 
DDL includes terms for defining records, fields, keys, and relationships. It should also 
provide the means to express a variety of user views and data base constraints. 
[Ref. 18: p. 5] 

The DML is a vocabulary for describing the processes (retrieving or changing) 
that can be performed on the data in the data base. There are two types of DML: 
procedural and nonprocedural. Procedural DMLs use high level programming 
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Figure 2.2 Realms of a data base management system. 

languages (such as COBOL and FORTRAN) to access the data base. They describe 
explicitly the actions to be performed on the data base. Nonprocedural DMLs simply 
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state what is wanted but not how to obtain it. Nonprocedural DMLs are directed 
towards noncomputer specialists. 

5. DBMS Utilization 

Data base management systems are valuable wherever there is a requirement 
to manage an integrated data base. Continuing advances in computers have resulted in 
similiar advances in DBMS. They now operate on microcomputers and workstations as 
well as the large mainframe computer systems. DBMS are used in business 
applications, the military (such as wargaming and decision support systems), and in 
research facilities. All three of these areas share the identical problem of trying to 
manage vast amounts of data in a timely and effective manner. NPS has chosen 
ORACLE as the relational DBMS for their DSS C2 workstation. Representative data 
created during play of wargaming scenarios and provided by NOSC, will be utilized as 
a surrogate for actual operational data. This data provides a wide spectrum of process 
records for the analyst and system designer alike. 

C. SUMMARY 

Chapter II defined DSSs as a computer-based, interactive system that 
incorporated the experience and instinct of the decision-maker to analyze hypothetical, 
"what if' type questions. These systems require flexibility, user-friendliness, a natural 
language capability, timeliness, and evolutionary characteristics. The advantage that a 
DSS offers to the commander is the ability to improve the process, compare, and 
decide phases of the command and control decision-making process. In order for a 
DSS to support "ad hoc" queries from the user, a suitable data base management 
system is required. A DBMS is defined as a complex, usually large program which 
stores and retrieves data from a data base. Organizationally, the DBMS consists of 
three levels; the conceptual (or user's perception of the data base), the logical level 
(which defines the user's perceptions in terms of a particular DBMS), and the physical 
level (which contains the actual data itself). Specific applications for DBMSs include 
wargaming and decision support systems. However, a data base design is required 
before any system can be implemented and Chapter III describes the methodolgy used 
to design such a logical data base design. 
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III. A LOGICAL DATA BASE DESIGN USING SDM 



This chapter describes the procedures and format used to develop the logical data 
base for the C2 workstation using a Semantic Data Model. The first section analyzes 
the data received from the Naval Ocean Systems Center (NOSC). Then, the basic 
structure and models used in the logical data base design are described with particular 
attention given to the Semantic Data Model. Specifically, the characteristics, benefits, 
purpose, and format of the SDM are discussed. Finally, a narrative description of the 
SDM schema developed for the C2 workstation is provided with a detailed explanation 
of one of its entity classes. 

A. OVERVIEW 

What actually constitutes a data base design varies from author to author and 
certain areas tend to overlap. We will use the method suggested by David Korenke in 
his book Data Base Processing [Ref. 19]. According to Kroenke, data base design is a 
two-phased process consisting of a logical data base and a physical design. First, the 
user's requirements are examined and a conceptual data base structure is created to 
model their organization. This is called the logical data base design. In our case the 
logical design is represented using the SDM. Once this design is complete, it is 
formatted in terms of a particular DBMS. In our case this is a relational DBMS since 
ORACLE is the chosen DBMS for the workstation. This second step is called the 
physical data base design. 

Data base design is an intuitive and artistic process. There is no algorithm for it. 
[Ref. 19: p. 177] It is an interactive process with the goal to get closer to an acceptable 
design. The data base is a bridge between people and hardware and the designer must 
consider both these characteristics. The logical design specifies the needs of the people. 
The physical design maps the logical design into constraints of a particular program 
and hardware products. "The goal when developing a data base design is to make only 
uninteresting questions unanswerable." [Ref. 19: p. 206] 

B. ANALYSIS OF DATA 

The data used in this design was supplied by NOSC in San Diego, Ca. NOSC 
wrote the computer program to extract this data from the RESA wargame's 
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blackboard and the data are updated once every minute of game play. The data are run 
through a TAPE_PIPE.EXEC computer program, also supplied by NOSC, which 
separates the data into six associated files corresponding to RESA tables. The common 
denominators between all files are the game time and associated slot number. These are 
control numbers used by the computer program as it extracts the data from the 
blackboard. They also serve a secondary purpose, which is to relate the separated data 
files to one another. A sample listing of data, their associated fields, and an 
explanation of their interrelationships is provided in Appendix C. It is this data that 
will be used to develop the logical data base and relational data base design. 

C. LOGICAL DATA BASE DESIGN 

The logical data base design specifies the logical format of the data base. It is 
sometimes called the schema or logical schema. It identifies the records maintained, 
their contents and the relationship among the records. The contents of each record 
contains field names and their required format. As requirements are evaluated 
constraints on data items are identified. There are three types [Ref. 19: p. 179]. A field 
constraint limits the value a given data item may have. Intrarecord constraints limits 
values between fields within a record and interrecord constraints limit values between 
fields in different records. The level of record detail depends on the designer. There are 
few records if the model is highly aggregated and generalized or many records if very 
detailed. 

In developing the schema the assigning of data items is relatively straightforward 
for two-thirds to three-fourths of the record types, but problems do arise. Some of 
these files may need to be combined or separated, and if this is done, does it make the 
design more effective? The designer must also allow for growth and anticipate future 
requirements of the user. A final problem encountered concerns "implied" data. This is 
an item that is needed to meet a requirement but is not visible to the user. [Ref. 19: p. 
182] 

The second step in developing the schema is determining the relationships among 
the records [Ref. 19: p. 182]. The designer must model how the user sees the 
relationships. This is done intuitively, but in designing relationships, the designer must 
distinguish between theoretical and useful ones. A theoretical relationship can exist 
logically but, in practice, may never be needed. "In general, if there is any question 
regarding whether a relationship is useful or not, then the relationship should be 
included in the logical schema." [Ref. 19: p. 186] 
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1. Logical Design Structures (Primitives) 

Before it is possible to design files and relationships, it is necessary to 
understand the foundations of data modeling. The data base design is only a 
representation of reality. It is a model of some activity, a conceptual presentation of 
real world structures or primitives. [Ref. 19: p. 205] 

Primitives in the real world consist of objects, object classes, properties, 
property value sets, facts, and associations. An object is defined as some phenomena 
that can be represented by nouns, such as a ship. Object classes (ships) are merely 
groups of objects formed by generalizations. Properties are the characteristics of these 
objects and the collection of all values a property can have is called the property value 
set. The intersection of a given object with a given property value set is called a fact. 
This concept is illustrated in Figure 3.1. Finally, an association is the connection of 
objects of the same or different classes and they may also have properties. [Ref. 19: p. 
207] 



HEIGHT PROPERTY 
VALUE SET 



f N 







FACT 


f 

RAY HARRIS 


67 INCHES 


- 

27 YEARS OLD BASKETBALL SKILL 


OBJECT 


77 INCHES 
74 INCHES 
59 INCHES 





V J 



Figure 3.1 Example of primitive fact. 

Only a representation of these real world primitives is used in designing a data 
base. A 74 inch person can be inserted into a car or ship, but not into a data base. 
Therefore, data base experts have defined a conceptual primitive for each of the real 
world primitives. They are entity, entity classes, attributes, domain (which is the 
collection of all values an attribute can have), a value (which is the intersection of a 
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given entity with a given domain), and a relationship. The equivalences between real 
world and conceptual primitives is depicted in Figure 3.2 [Ref. 19: p. 209]. These 



Figure 3.2 Equivalencies between real world and conceptual primitives. 

conceptual primitives will be used in the development of the logical data base design. 

2. Data Base Models 

All data bases are a model of some system in the real world. The actual data 
represents events, frozen in time, that occurred in the application environment. Any 
change to the data base should only occur if a similiar change occurred in the 
environment. This means the structure of the data base should "mirror" the structure of 
the system it models. It is easier for the data base designer to build and modify the 
data base when it is based on naturally occurring structures in the environment. This 
same rationale can be applied to the data base user. If data bases are described in 
terms and concepts familiar to the user, then it should become easier to understand 
and employ the data base. [Ref. 20: pp. 351-352] 

A data base model is defined as a logical schema "specified in terms of a 
particular data base description and structuring formalism and associated operations." 
[Ref. 20: p. 352] These models are important tools for designing both logical and 
physical data bases. There are many useful models available, such as the Entity- 
Relationship model, the Relational Data model, and the CODASYL DBTG model. 
They range from being human-oriented on one side to machine-oriented on the other. 
All these models have one thing in common; they describe the structure and processing 
of a data base. 

The Semantic Data Model (SDM), as developed by Hammer and McLeod and 
first published in 1981 [Ref. 20], will be used for the development of the logical data 
base design. This model is human oriented, and because of its semantic nature, SDM 
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is recommended for logical data base design. Hammer and McLeod do not believe the 
data structures provided by contemporary data base models, such as those listed above, 
adequately support the design, evolution, and use of complex data bases. They are 
significantly limited in their capability to express the meaning of the data base to its 
corresponding application environment. 

The semantics of a data base defined in terms of these mechanisms are not 
readily apparent from the schema; instead the semantics must be separately 
specified ov the data base designer and consciously applied by the user 
[Ref. 20: p. 352]. 

We believe that SDM provides better facilities (than models like the Relational Data 
Model or the Entity- Relationship Model) for expressing meaning about data, avoiding 
confusion, and documenting design decisions and constraints [Ref. 19: p. 194]. 

3. Goal and Benefits of SDM 

The goal of SDM is to enable the data base designer to directly incorporate 
more meaning and relationship about the data into the logical schema. It serves as a 
modeling mechanism to express the natural structure of the environment in the 
structure of the data base design. SDM provides several benefits to the user. First, it is 
a formal technique to describe meaning about the data base. It provides precise 
documentation of the data and it is a communication medium which allows the user to 
determine what information is contained in the data base. Second, SDM allows the 
construction of user interfaces to the data base which improves the process of 
identifying and retrieving relevant information. These can be front-ends to existing data 
base management systems (DBMS) or query languages for new DBMSs. An additional 
benefit of SDM is it supports effective and structured design of data bases. 
[Ref. 20: pp. 352-353] 

4. Design Criteria of SDM 

The Semantic Data Model was developed by Hammer and McLeod to meet a 
number of criteria not met by the contemporary data base models. They felt the data 
base should be designed to provide specific meaning to a large portion of the data base. 
In addition, it should support a view related to the meaning of the data base and have 
a structure which supports different ways of viewing the same information. This 
requires a data base model be 

1. Flexible - allow for multiple and coequal views of data 
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2. Logically redundant - values of components can be derived from other 
components in the data base 

3. Integrated - this describes the relationships of a data item viewed in different 
ways 

The last essential criteria for SDM is it must be able to describe relevant entities 
(which represent objects in the real world environment), groups of these entities, their 
relationships, and the interrelationships among the groups. [Ref. 20: pp. 353-354] 

5. Structured Format of SDM 

We will now discuss the SDM format which is displayed in Figure 3.3 
[Ref. 19: p. 213]. A data base is viewed as a collection of entities that correspond to 



ENTITY JCL ASS _NAME 

description: 

interclass connection: 

member attributes : 

A ttribute jiame 

value class'. 

mandatorv 

multivalued, no overlap in values 
exhausts value class 
not changeable 
inverse: Attribute name 
match: Attribute_name ot ENTITY_CLASS 
on Attribute_name2 

derivation: 

class attributes: 

Attribute _name 

description: 

value class : 

derivation: 

identifiers: 

Attribute_name 1 + (Attribute_name2 + (...) ) 



Figure 3.3 SDM format of entity class description. 

the actual objects in the application environment. These entities are organized into 
classes that are meaningful collections of entities. The class name identifies the class of 
entities and must be unique with respect to all other class names in the schema. The 
description defines the purpose and content of the class. It describes the specific nature 
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of the entities and indicates their significance and role in the application environment. 
[Ref. 20: pp. 355-356] 

The class is composed of a collection of members or entities. These entities 
correspond to various kinds of objects in the application environment such as concrete 
objects, events, categorizations or syntactic identifiers (STRINGS). STRINGS are any 
character string which the designer wants. There are two types of attributes which 
describe the members of the class or the class as a w'hole: a member attribute or class 
attribute. The member attribute describes an aspect of each member of a class by 
logically connecting the member to one or more related entities in the same or another 
class. The class attribute describes the property of a class as a whole and not any 
particular member. [Ref. 20: pp. 356-357] 

A class can either be a base class or a nonbase class. A base class is defined 
independently of all other classes whereas a nonbase class does not have an 
independent existence, but is defined in terms of one or more other classes. These 
nonbase classes are related by means of an interclass connection which describes how 
the class is constructed. There are two types; a subclass connection is a class that 
contains some but not necessarily all of the members of another class and the grouping 
connection has members that may themselves be viewed as classes. [Ref. 20: pp. 
357-358] 



Data base entities and classes have attributes that describe their characteristics 
and relate them to other entities. These member attributes have value classes which 
may be an entity in the data base or a collection of such entities. The value class 
contains the permissible values of that attribute and may be derived from other values 
in the data base. There may or may not be constraints and relationships on member 
attributes. If any, they are defined as follows. 

1. multivalued- this is like a repeating field, there is more than one. For example, a 
ship mav be described as a particular tvpe such as a destrover. This would be 
considered sinelevalued since it can not 'be defined as any other type. However, 
this same ship'" mav have many kinds of weapon systems. Therefore weapons, if 
listed as a member attribute would be multivalued. 

2. Mandatorv - the null value is never accepted. Tvpe from the previous example 
can be thought of as a mandatorv constraint.. EVery ship must be described by 
type, cruiser "or destroyer, whenever it is listed in the' data base. 

3. Not changeable - the value of an attribute must remain the same. This means 
the value, once set, cannot be changed except to correct an error. If the tvpe of 
ship listed was wrong, then the value can be changed. 

4. Exhaustive - everv member of the value class must be used. For example, if 
engines were listed as a member attribute of an entitv class called SHIPS, then 
every engine entity listed must be an engine on some ship. 
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5. Non overlapping - a member of the value class can be used at most once or not 

at all. If the engine of the entity class SHIPS were specified as non-overlapping, 
then this means that any engine listed can be in only one ship. 

6. Inverse - this causes two entities to be contained in each other. For example, if 

two entity classes were defined as PITCHERS and RECIPES then these would 
be inverses if a member attribute from each entity class had a value class listed 
as PITCHERS and RECIPES. Let us assume that kind_pf_recipe used is a 
member attribute of PITCHER and its value class "is REdPES, and 
pitcher_recipe usedjn has a value class of PITCHERS. These then are 
considered to”be inverse of each other. 

7. Matching - a member of one entity class is matched with a member of another 

entitv class. This means the value ol an attribute in one of the members is 

moved to the other member in another entity class. As an example, let SHIPS 
and ASSIGNMENTS be defined as entity classes with member attributes of 
Captain and Officer respectively. If Captain is matched to Officer of 
ASSIGNMENTS'^ then the value' of Captain is determined bv the value of 
Officer from ASSIGNMENTS for a particular ship. 

S. Derivations - these are statements clarifying how to derive an attribute. They 
can also be used to specify relationships among members in the same entity 
class. An example is a cla'ss attribute of total number _of_ships. This is theri 
derived by summing the total number of ships lisled in the entity class SHIPS. 

Finally, the identifiers are unique keys which identify individual records. This is the 

format used to develop the SDM schema described in the next section and Appendix 

D. [Refs. 19,20: pp. 213-224. 363-365] 



D. DESCRIPTION OF THE SDM SCHEMA FOR THE C2 WORKSTATION 

The identification of the data extracted from the RESA wargame has already 
been completed by the Naval Ocean Systems Center (NOSC). We transcribe the data 
into an SDM schema and tailor it to meet the needs of NPS, occasionally deleting 
certain items which seemed to have no real value to the user. 3 The information in this 
process was obtained from the blackboard in the RESA data base, while constraints on 
the data were identified by evaluating the sample output data supplied by NOSC. The 
data are broken down into six basic areas or entity classes based on the type of 
information available to the user. These classes are: 

1. Active units - this describes all units, whether hostile or friendlv, which are 
participating in the wargame scenario. Units can be ships, shore bases, aircraft, 
submarines or cruise missiles. 

2. Remote detections - contains the apparent latitude and longitudinal position of all 
detected targets such as aircraft or cruise missiles. 

3. True position- this entitv class provides ground-true latitude and longitudinal 
position lor each active unit in the game. 

4. Inflicted damages- identifies what unit was damaged, .the time it occurred, and 
which general areas sustained damage. For example, it will indicate if a ship is 
sinking" or its maximum speed possible after being damaged. 



3 Those items deleted were discussed with personnel at NOSC to confirm their 
intended use in the data base. 
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5. Dynamic information - contains specific information for each active unit. It 
includes the percent of damage suffered by a unit and the amount of equipment 
remaining after being damaged. In addition, it provides an accounting for 
weapon expenditures during combat operations by keeping track of the number 
of missiles remaining and other similiar items. 

6. Engagement data- provides information on aircraft and ships engaged in combat 
operations. It includes calculated probabilities on aircraft air-to-air missile 
strikes and on ship launched missiles for interception of incoming cruise 
missiles. It defines the current position of both the attacking unit and target 
and the status of the target after the engagement i.e., whether it was hit “or 
destroyed. 

E. DESCRIPTION OF SDM ENTITY CLASS ACTIVEJJNITS 

It should be noted that certain formats in the domains of the value classes listed 
in this schema were changed from those originally specified in the RESA blackboard. 
This was done to accommodate the players of the wargame, since this workstation will 
also be used as a DSS to interact with the game on a real time basis. 4 For example, it 
will be much easier to read the name of an item than trying to interpret what a 
particular number is supposed to mean, especially when the range of possible total 
values exceeds ten. Since this workstation is supposed to assist the decision-maker we 
felt it was necessary to make these changes. The entity class ACTIVE_UNITS is 
shown in Figure 3.4 to illustrate the SDM concepts discussed in this chapter. The 
complete SDM schema is listed in Appendix D. 

ACTIVE_UNITS describes those units which are participating in the war 
scenario. The member attributes for each specific unit are Name, Status, View, Type, 
Assigned_target_of_unit, Bomb_hits, and Missile Jiits. The unique identifier for this 
entity class is Name since no two names within ACTIVE_UNITS are the same. The 
member attribute Name has a value class of UN'IT_N'AMES. This is a subclass of 
STRINGS having a maximum length of eight characters w r hich identifies the name of 
each unit. It is considered mandatory, along with member attributes Status, View, and 
Type because these are the minimal members that must be contained in the entity class. 
If there is no Name then no other information should be provided. If there is a Name 
then the minimum information needed for each unit are Status, which describes the 
present condition of the unit, View, w’hich identifies the unit as hostile, friendly or 
neutral, and Type, which identifies whether the unit is a ship, submarine or aircraft. 
The value class of Status is UN1T_STATUS W'hich is a subclass of STRINGS whose 
format is an integer from 0 to 10. For example, 0 indicates if the unit is being deleted. 2 
if the unit is on station and 3 if the unit is proceeding. View has a value class equal to 

4 NOSC only uses their workstation for post game analysis. 
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ACTIVEJJNITS 

description : Contains names, pointers, and other "quick.reference" data 
for all active ships, shore bases, aircraft flights, ana cruise missiles. 

member attributes'. 

Name 

value class : UNIT_NAMES 
mandatory 

Status 

description: contains present condition of unit, for example, 
sinking or on station. 

value class: UNIT_STATUS 
mandatory 

View 

description : identifies character of unit, for example, hostile. 

value class: DISPOSITION 
mandatory 

Type 

description: identifies kind of unit, for example, submarine 
or cruise missile. 

value class: TYPE_UNIT 
mandatory 

Assigned jtar get _ofjmit 

description: it indicates the target unit is attacking. 
value class: UNIT_NAMES 

Bombjiits 

description: contains number of bomb hits a unit received 
during a current game cycie. 

value class: NUMBER_EPU 
multivalued 

Missile Jiits 

description: contains number of missile hits a unit received 
during a current game cycle. 

value class: NUMBER_EPU 
multivalued 

identifiers: 

Name 



Figure 3.4 SDM entity class ACTIVE_UNITS. 
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DISPOSITION. This is a subclass of STRINGS whose format is an integer from 0 to 
10. In this case a 1 indicates the unit is neutral, a 2 if friendly, and 3 if hostile. The 
value class Type is TYPE_UNIT. This is another subclass of STRINGS whose format 
is an integer from 0 to 10. Examples of these values are: l identifies the unit as an 
aircraft, 5 identifies a cruise missile and 4 indicates an aircraft carrier. 
Assigned_target_of_unit identifies which target the unit is currently attacking such as an 
aircraft or cruise missile. There is no mandatory value for this member attribute since 
it can assume a null value. There are times when a ship may not be engaged in combat 
operations. Its value class is UNIT_NAMES. Bombjiits and Missile_hits are member 
attributes that are considered multivalued attributes. An individual unit can receive 
more then one hit by a bomb or be hit by more then one missile. They share the same 
value class NUMBER_EPU. This identifies the number of explosive power units 
(EPUs) received by a unit. It is a subclass of STRINGS whose format is an integer 
from 0 to 200. The rest of the entity classes defined in the SDM for the C2 workstation 
are contained in Appendix D. 

F. SUMMARY 

Chapter III describes the methodology used in the logical data base design. This 
design contains the conceptual data base structure which models the user's 
requirements for the organization. The Semantic Data Model was used to develop the 
logical schema for the C2 workstation based bn data received from the Naval Ocean 
Systems Center. This model was chosen over existing data base models like the 
Relational Data Model or Entity_Relationship Model because it provides better 
facilities to express meaning about the data, avoid confusion and document design 
decisions and constraints. SDM is a mechanism to describe the meaning of the data 
base. It provides a variety of semantic-based user interfaces to the data base, and it is 
the foundation of effective and structured design for data bases. The basic format of 
SDM consists of an entity class (a group of entities corresponding to actual objects in 
the environment), member attributes (characteristics of the entity class), and a value 
class (which are the permissible values an attribute may have). 

A narrative description of the SDM developed for the C2 workstation was 
provided in the last section. It was divided into six basic entity classes. The first class 
described individual characteristics of all active units in the wargame and was described 
in detail in this chapter to illustrate the concept of SDM. The next two identified 
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apparent and true locations of detected targets and active units respectively. The fourth 
entity class identified areas of damage that a unit sustained while the next one 
contained specific information on the amount of damage received and expenditure of 
resources of a particular unit. The last class described data on units engaged in actual 
combat. This schema forms the basis for developing the relational data base design 
which is described in Chapter IV. 



32 



IV. A RELATIONAL DATA BASE DESIGN USING ORACLE 



This chapter is divided into two major sections. The first describes the criteria, 
components, and format used in developing a relational data base design. The second 
section transposes the SDM in Appendix D into a relational data base design for the 
C2 workstation. It begins by describing the current system used by NOSC to extract 
data from the RESA wargame and to transfer it to their data base management system 
(DBMS) on their own workstation. This system is used to identify similiar areas of 
work which will be required before NPS can implement their own DBMS. In addition, 
this section describes that portion of the design necessary to provide the user the 
capability to access the data on a real time basis. Finally, the last part of this section 
contains the detailed structure of the relational data base design supported by tables of 
data and several sample SQL queries to illustrate ORACLE'S data manipulation 
language. 

A. METHODOLOGY OF A RELATIONAL DATA BASE DESIGN 

The physical data base is the second stage of the data base design. The logical 
schema (the SDM model) is transformed into the particular data constructs of a 
DBMS. This will be a relational data base design compatible with ORACLE and will 
produce detailed specifications of the data base structure. These specifications will then 
be used during data base implementation to write source statements defining the data 
base structure to the DBMS. 

1. Terminology 

The basic format used in a relational data base design is a two-dimensional 
table called a relation. The relation, or fiat file, containing single-valued entries, is 
constructed of columns and rows of data. The columns are called attributes while rows 
are called tuples. No two tuples in a single relation can be identical. All entries in a 
column must be of the same kind or category, ie., all ships or all names. These entries 
represent possible values for an individual attribute and the range of permissible values 
is called a domain. [Ref. 19: p. 243] 

The terms relation, attribute, tuple, and domain correspond directly to SDM 
terminology. This makes it easier to transpose the SDM schema into a relational data 
base design. Entity classes in SDM may be transposed into relations while SDM 
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member attributes are like tuples. Attribute names in SDM are very similiar to 
relational attributes or columns and STRINGS value classes in SDM directly 
correspond to domains. The distinction in the last case is that tuples are not permitted 
to contain other tuples in relations which is allowed in SDM. [Ref. 19: p. 245] 

2. Design Criteria 

Again, there are no set of rules to follow in all circumstances when creating a 
relational data base design, but there are several criteria for producing an effective 
design [Ref. 19: p. 307]. The first step is to eliminate any modification anomalies. 
These are unexpected consequences that occur when changing data. There are two 
general categories: 

1. Deletion anomaly - this is the loss of information about two entities with only 
one deletion. 

2. Insertion anomalv- this is the gain of information about two entities with one 
insertion. Stated 'negatively, it means information about an entitv cannot be 
inserted until there is additional information about another entity. 

These anomalies can be eliminated by creating two new relations called a projection. A 

disadvantage in doing so is that this causes undesirable interrelation constraints since 

two relations share the same attribute. It is not always possible to eliminate all 

anomalies from a relation, but through the use of "Normal Forms" designers can 

attempt to reach this goal. A normal form is a process that classifies an anomaly and 

then describes a way to prevent it from happening. Refer to Kroenke's book on Data 

Base Processing , Chapter 8, for a detailed explanation of these forms [Ref. 19]. 

The last two criteria or goals for a relational data base design are relation 
independence and ease of use. If a relation can be modified without regard to another 
then the relation is independent. Ease of use requires that relation structures be 
familiar and seem natural to the user. When all these criteria conflict, as they 
sometimes do, then the designer must assess the priorities and make the best possible 
compromise. 

3. Components and Format 

This section defines the three major components of a relational data base 
design; relations , domains and attribute! domain correspondences, and interrelation 
constraints [Ref. 19: pp. 311-321]. The first component specifies the name, attribute, 
and key of the relation. The generalized format is displayed in Figure 4.1. In addition, 
the relation table will contain four to five tuples of example values from the domain 
associated with each attribute. The order of the values listed will match, one-to-one. 
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RELATION_NAME (attributel, attribute2, ...) 
A'ey(s): relation attribute 

Attribl Attrib2 Attrib3 Attrib4 


Attrib5 


Attrib6 


value 1 


value2 


value3 


valued 


valueo 


valued 


value2 












value3 












valued 












valuei 













Figure 4.1 Format for relations. 

the order of the listed attributes. Each defined relation will be listed in separate figures 
compared to only one figure for the remaining components. The second component 
specifies domains and attribute; domain correspondences for the entire relational data 
base design. Domains are defined both physically and semantically because it is 
possible that two domains will have the same appearance but have very different 
meanings. The structure for this component is depicted in Figure 4.2. This table will 



Domain Name 

DOMAIN 1 
DOMAIX2 
DOMAIN3 


Format and Meaning 

numeric YYMMDD 
positive inteaer less than 10 
CHAR(IO); names of ships 


Attribute 


Domain 


RELATION. attributel 


DOMAIN1 


RELATION.attribute2 


DOMAIN2 



Figure 4.2 Format for domains and attribute/domain correspondences. 

contain the complete list of domains and attribute/domain correspondences within the 
Relational Data Base Design. The final component structure, which specifies 
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interrelation constraints, is listed in Figure 4.3. These components are the minimal 
ones and can be augmented by additional documentation for clarification. 



RELATION 


( attribute 1) 


SUBSET OF 


RELATION- 


(attribute2) 


RELATION 


(attributes) 


SUBSET OF 


RELATION 


(attributed) 



Figure 4.3 Format for interrelation constraints. 



B. A RELATIONAL DATA BASE DESIGN FOR THE C2 WORKSTATION 

The relational data base design is very similiar to the design used at the Naval 
Ocean Systems Center (NOSC) in San Diego, California. What makes it different, 
besides being tailored to the needs of the Naval Postgraduate School (NPS), is the 
additional real time requirement to access data during game play. 

1. Description of the System Used by NOSC 

The system at NOSC extracts the data in a sequential manner. It goes to each 
table, extracts the data and then moves onto the next set of data items. This data is 
then sent to tape and run through their TAPE_PIPE.EXEC program to organize the 
data into six files. The data is then shipped to their own workstation, an HP 9020, and 
loaded into their relational DBMS, INFORMIX. At this time, NOSC is using the data 
strictly for post wargame analysis. 5 The Naval Postgraduate School will also use the 
data for post game analysis, but at the same time, NPS wants to permit players of the 
wargame to access this same data during game execution. This requires a different 
design for the ORACLE DBMS. 

2. Implementation Requirements for the NPS DBMS 

To accommodate this plan, NPS will have to develop their version of NOSC's 
TAPE_PIPE.EXEC program to organize the data. This program only works when 
using a tape as an input. NPS will use a disk storage device instead of a tape. After the 
data are run through this program, they will be sent to the Sun workstation via the 
ETHERNET, which is a 10 Megabit-per-second coaxial cable local area network 
facility [Ref. 21: p. 10], and written to a disk file. This will require a second program to 



5 The author obtained this information through a telephone conversation with 
personnel from NOSC. 
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format the data for transmission over the net. 

Once information is on the disk, it is then necessary to reformat the data into 
ORACLE terms for entry into the appropriate relational table. The design of these 
tables will correspond to the way the data are extracted from the RESA data base. 
Too many changes or additions in the original design would require a modification of 
the initial program which extracts the data. This should not be necessary. At this time, 
the relations are logically structured. Only through use of the system, or if the 
requirements change, will it prove necessary to make changes in the current 
organization of the data base. 

3. Design Requirements to Assure Real Time Data Access. 

To permit the user to access this data during play of the game the DBMS 
should be set up into duplicate relational tables. 6 Instead of the initial six tables used 
at NOSC, there would now be 12. Only the names and the amount of data, not the 
type, would be different. As data are received at the workstation and converted into 
ORACLE format, they would be written to 12 relational tables. The first six tables 
would contain the complete set of information retrieved. These would be the historical 
files. The second six would contain only the most recent update of information 
provided from the game. The advantage of this arrangement is it reduces the time to 
retrieve data from the system. The current will be much smaller then historical files, 
and therefore, require less time to search. 

Information is collected once during each game cycle (one minute of game 
play) for all six relations, sometimes more if the information involves the remote 
detection of targets. Then, during the next game cycle, this information is collected 
again. It may have changed or their may be additional data or some data may have 
been deleted. Each game cycle will be kept in the historical files. Only the data in the 
last one to five game cycles will be kept in the second set of relational tables. As new 
information is written to the table, those records with the oldest game time will be 
deleted which eliminates any problems that would normally arise due to modification 
anomalies. This keeps the access time down to a minimum when querying the data. 
These tables can grow very large in size depending on the length and complexity of the 
wargame. Required storage may run anywhere from 55 to 100 Megabytes of disk 
space.' 



6 This was recommended by NOSC. 

Potential storage requirements were identified by NOSC. 
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There is one other item of importance concerning the program that extracts 
the data from the blackboard. The program keeps control of data by using a game time 
and slot number for all records of data extracted from the game. There is a unique slot 
number for every record extracted within the same game cycle. As such, there will be 
two additional attributes listed in each relation; one for a slot number and one for a 
game time. Only six tables are listed but 12 will be required during implementation of 
the system. The format, which is the same for both sets of relations, is displayed in 
detail in the next section. 

4. Relational DBMS for the C2 Workstation. 

The format used to depict the relational design consists of three sections. The 
first identifies the individual relations, which will be duplicated in the implementation 
phase. The other two sections, domains and attribute! domain correspondences and 
interrelation constraints will be used to define the fields of the attributes in the DBMS. 



REMOTE_DETECTION (unit_detected, apparent-latitude, apparent_longitude. 




slot_number, game_ 


time) 




Key(s): Unit_detected + slot_ 


_ number + apparent_latitude + apparent 


. longitude + game_time 






Note: Name and slot number can be repeated more than one time in a game 


cycle depending on which unit detected the target. Therefore, both unit 
detected and slot_number are multivalued with respect to game_time. 


unit 


apparent 


apparent 


slot 


game 


deiected 


latitude 


longitude 


number 


time 


BK102 


55 32 N 


23 12W 


32 


24 


BK133 


58 30N 


24 16W 


33 


24 


P2012 


45 16S 


32 29 W 


34 


24 


BF201 


72 45N 


55 6SE 


35 


24 


BK102 


56 32N 


24 12W 


32 


24 



Figure 4.4 Relation REMOTE_DETECTION. 
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ACTIVE_UNIT (name, status, view, type, assigned_target, bomb 


_hits, 






missile_hits, slot_number, game_time) 








Key(s): 


Name + 


game_time 












Note: 1 


. Bomb_hits and missile_hits are multivalued with respect to name. 


2. Name is multivalued with respect to game_time. 














assigned 


bomb 


missile 


slot 


game 


name 


status 


view 


type 


target 


hits 


hits 


number 


time 


Petro 


2 


3 


2 


0 


0 


0 


1 


34 


Nimtz 


6 


2 


4 


0 


0 


0 


2 


34 


BklOl 


J 


3 


1 


0 


0 


0 


3 


34 


PI 024 


3 


3 


5 


Nimtz 


0 


0 


4 


34 


Petro 


2 




2 


0 


13 


0 


1 
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Figure 4.5 Relation ACTIVE_UNIT. 



TRUE_POSITION (name_of_unit, true_latitude, 
game_time) 

Key(s): Name_of_unit +• game_time 

Note: Name is multivalued with respect to game 

name apparent apparent 

of unit latitude longitude 


true_longitude, slot_number, 
_time. 

slot game 

number time 


VF203 


23 34N 


34 12W 


3 


23 


VF123 


16 23S 


32 40 E 


1 


24 


Vinson 


32 23S 


24 12E 


2 


24 


Engls 


32 24S 


25 12E 


3 


24 


P2034 


13 21S 


24 35 W 


4 


24 



Figure 4.6 Relation TRUE_POSITION. 
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Figure 4.7 Relation DYNAMICINFORMATION. 
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Figure 4.S Relation INI 1 ICTliD DAMAGE. 
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1'igiire 4.9 Relation 1 : N G A G I : .\ 1 C N T_ D A T A . 



Domain Name 


Format and Meaning 


DAMAGE 


integer, 0 to 2; identifies condition of taraet after 
engagement. Integers are defined in BBCODE.def 
table" 6.12 in RESA's data base. 


DISPOSITION 

INDICATOR 


integer, 1 to 10; identifies unit as friendly or hostile 

integer, 0 or 1; flag identifys specific areas where unit 
sustained damage ~ 


ITEM_NAME 

MAX_SPEED 


CHAR(10); names of items attached to a unit 

integer, 0 to 60; maximum speed (knots) of a 
damaged ship 


MINUTES 


integer, 0 to 65000; game time when unit was 
damaged 


NUMBER_EPU 


integer, 0 to 200; explosive power units (EPUs) a unit 
may receive during current game cycle. 


NUMBER_FIRED 


integer, 0 to 10; number of air-to-air or surface-to-air 
missiles fired by a unit 


NUMBER_ITEMS 


integer, 0 to 5000; equipment or weapons available 
on a unit 


PARKED_AIRCRAFT 


integer, 0 to 1000; number of parked aircraft that 
were damaged 


PERCENTAGE 


real number, 0.0 to 1.0; identifies amount of damage 
or probability of hits on a unit 


POSITION.LATITUDE 


LLMMSSX; where LL is an integer 0 to 90, MM 
(minutes) is an integer 0 to 60. $S (seconds) is an 
integer 0 to 60, X is a CHAR whose value is N\ E, S 
or \V. Position is given in degrees. 


POSITION_LONGITUDE 


LLLMMSSX; where LLL is an integer 0 to 180, 
MM (minutes) is an integer 0 to 60. S5 (seconds) is 
an inteser 0 to 60, X is a CHAR whose value is N, 
E, S orAV. Position is given in degrees. 


REPORTING 


integer, 0 to 7; indicates status of report for damaged 
units. Integers are defmed in BBCODE.def table oil 8 
in RESA data base 


SENSORS_DAMAGED 


integer, 0 to 24; number of sensors that were 
damaged on a unit 


TYPE_MISSILE 


CHAR(8); names of missiles launched from an 
aircraft or ship 


TYPE_UNIT 


integer, 0 to 11; classifies unit, for example, ship or 
aircraft. Integers are defmed in bBCODE.def table 3.0 
in the RESA data base 


UNIT.NAMES 


CHAR(8); names of ships, aircraft flights, shore 
bases, ana cruise missiles 


UNIT_STATUS 


integer. 0 to 9; current condition of unit. Integers are 
defined in BBCODE.def table 5.6 in RESA data base 


YES 


integer, 0 or 1; indicates if unit has been detected 


Figure 4.10 


Domains of relational attributes. 
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Attribute 


Domain 


ACTIVE_UNITS.name 

ACTIVE_UNITS. status 

ACTIVE_UNITS .view 

ACTIVE_U NITS. type 

ACTIVE_UNITS.assigned_target_of_unit 

ACTIVE_UNITS.bomb_hits 

ACTI VE_UNITS . missile_hit s 

ACTIVE_UNITS.slot_number 

ACTIVE_UNITS.game_time 


UNIT_NAMES 

UNIT_STATUS 

DISPOSITION 

TYPE_UNIT 

UNIT_NAMES 

NUMBER.EPU 

NUMBER_EPU 

CONTROL.NUMBER 

CONTROL_NUMBER 


RE\10TE_DETECTI 0 NS ,apparent_latitude 

REMOTE_DETECTIONS.apparent_longitude 

REMOTE_DETECTIONS.name_of_unit_detected 

REMOTE_DETECTIONS.slot_number 

REMOTE_DETECTIONS.game_time 


POSITION_LATITUDE 

POSITION_LONGITUDE 

UNIT_NAMES 

CONTROL_NUMBER 

CONTROL_NUMBER 


TRUE_POS ITIO N .true_latitude 

TRUE_POSITION.true_longitude 

TRUE_POSITION.name_of_unit 

TRUE_POSITION'.slot_number 

TRUE_POSITION.game_time 


POSITION_LATITUDE 

POSITION_LONGITUDE 

UNIT_NAMES 

CONTROL_NUMBER 

CONTROL_NUMBER 


INFLICTED_DAMAGE.time_of_damage 

INFLICTED_DAMAGE.damaged_unit 

I N FLI CTE D_DAM AG E .base 

INFLICTED_DAMAGE.fuel 

INFLICTED_DAMAGE. stores 

INFLICTED_DAMAGE.sam_sites 

I N FLI CTE D_DAMAGE . sinking 

INFLICTED_DAMAGE.weapon_system 

INFLICTED_DAMAGE.aircraft 

INFLICTED_DAMAGE.number_devices 

INFLICTED~DAMAGE.view 

INFLICTED_DAMAGE.report_status 

INFLICTED_DAMAGE.speed 

INFLICTED_DAMAGE.slot_number 

INFLICTED_DAMAGE.game_time 


MINUTES 

UNIT_NAMES 

INDICATOR 

INDICATOR 

INDICATOR 

INDICATOR 

INDICATOR 

INDICATOR 

PARKED_AIRCRAFT 

SENSORS_DAMAGED 

DISPOSITION 

REPORTING 

MAX_SPEED 

CONTROL_NUMBER 

CONTROL_NUMBER 



Figure 4.1 1 Attribute/ Domain correspondences. 
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Attribute 



Domain 



DYNA.MICS_INFORMATION.name 
D YNAMICS_INF0 RMATIO N.store_damage 
DYNAMICS_INFO RMATIO Ndiull_damage 
DYNAMICS_INFORMATION.sam_damage 
DYNAM ICS_INFO RMATIO N.topside_damage 
DYNAMICS_INFORMATION.fuel_damage 
DYNAMICS_INFORMATION.identification 
DYNAMICS_INFO RMATION.remaining 
DYNAiMICS_INFORMATION.slot_number 
DYNAMICS_INFORMATION.game_time 



UNIT.NAMES 

PERCENTAGE 

PERCENTAGE 

PERCENTAGE 

PERCENTAGE 

PERCENTAGE 

ITEM_NAME 

NUMBER_ITEMS 

CONTROL_NUMBER 

CONTROL_NUMBER 



ENGAGEMENT_DATA.name_of_engaging_unit 

ENGAGEMENT_DATA.type_of_missile_fired 

ENGAGEMENT_DATA.number_of_missiles_fired 

ENGAGEMENT_DATA.probability-hit 

ENGAGEMENT_DATA. status 

EN G AGEMENT_DAT A.vievv 

ENG AGEME NT_ DATA .detected 

EN G AGEME NT_D AT A.target_status 

ENGAGEMENT_DATA.target_type 

ENGAGEME NT_D AT A .pro bability_hit_t arget 

E N GAGEME NT_DATA.unit_latitude 

EN G AGE MENT_D AT A.unit_longitude 

E N GAGE ME NT_ DAT A . target Jatitude 

ENGAGEMENT_DATA.target_longitude 

ENGAGEMENT_DATA.slot_number 

ENGAGEMENT_DATA.game_time 



UNIT_NAMES 

TYPE_MISSILE 

NUMBER_FIRED 

PERCENTAGE 

UNIT_STATUS 

DISPOSITION 

YES 

DAMAGED 

TYPE_UNIT 

PERCENTAGE 

POSITION_LATITUDE 

POSITION_LONGITUDE 

POSITION_LATITUDE 

POSITION_LONGITUDE 

CONTROL_NUMBER 

CONTROL_NUMBER 



Figure 4.11 Attribute/ Domain correspondences, (cont'd.) 

There are no interrelation constraints listed for this relational data base design. 
Interrelation constraints usually occur when entity classes are subclasses of other entity 
classes and when domains themselves are entity classes. In this case, the domains listed 
for each member attribute were defined as character STRINGS and not other entity 
classes. 
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5. Sample Data Base Queries 

This section serves two functions. First, it ties the SDM and the Relational 
Data Base Design together. Several queries are made on the previously defined 
relations in order to demonstrate what the analyst or player will be able to extract from 
the data base. In addition, it explains how ORACLE'S data manipulation language, 
SQL is used to retrieve data. 

a. Basic ORACLE SOL Commands 

The basic SQL commands are SELECT, CREATE, and INSERT. SELECT 
retrieves rows of data from a table, CREATE defines a new table, and INSERT enters 
rows of data into a table. The SELECT command is used for data base retrieval. It is 
the most common operation done with ORACLE. The basic SELECT command has 
two parts, called clauses; 

1. The SELECT clause - lists the columns from the table to be retrieved. 

2. The FROM clause - names the tables where the columns are located. 

The SELECT clause is always entered first and immediately followed by the FROM 
clause. These two commands would display all rows of information from the table. In 
order to select only specific rows of data, a WHERE clause must be added to the basic 
statements of SELECT and FROM, as demonstrated in Appendix B and in the next 
section. The WHERE command causes ORACLE to search the data in the table and 
retrieve only those rows that meet a search-condition. These conditions are varied by 
using AND, OR, BETWEEN and other clauses provided by ORACLE as clarifying 
statements. If more than one table of data needs to be queried for the information, 
then ORACLE will use a JOIN command to obtain the data. [Ref. 22] 

b. User Types of Queries 

These queries support two kinds of information retrieval. Figures 4.12 and 
4.13 describe questions of possible interest to an active player of the RESA wargame 
who would be using the workstation as DSS. The second type of information is 
characteristic of a question an analyst using the system might ask (Figure 4.14). It 
should be noted that each of the three figures uses a different SQL format for 
retrieving the data. They are a normal SELECT query, a subquery using two different 
relations, and a JOIN query, which pulls the information for the final answer from 
more than one table. This is different from a subquery. A subquerv may conduct 
operations on multiple tables, but it obtains the final answer only from one table. 
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Question: What is the last known position and time for the Soviet submarine 
Gulfl? 

SELECT (unit_detected, apparent_latitude, apparent_longitude, game_time) 
FROM (remote_detection_historical) 



WHERE unit_detected 
AND game_time > 


= gulfl 
38 






Result: 


unit 


apparent 


apparent 


game 


deiecied 


latitude 


longitude 


time 


Gulfl 


32 23N 


24 36E 


44 


Gulfl 


33 23N 


23 36E 


45 



Note: Current game time is 54. The user had to access the historical 

data table to be sure of obtaining an answer since current tables 
only contain data from the last few game cycles. 



Figure 4.12 Player SQL sample 1. 



Question: How much air activity has been detected over Petro? 

SELECT (count (distinct unit_detected)} 

FROM (remote_detections) 

WHERE (apparent_latitude, apparent_longitude) = 

GROUP BY game_time 



SELECT (true_latitude, true_longitude) 

FROM (active_unit) 

WHERE name = Petro 
AND game_time > 45 

AND true_latitude BETWEEN (true_latitude + 2 
and true_latitude - 2) 

AND true_longitude BETWEEN (true_longitude + 2 
and true_longitude - 2) 



Figure 4.13 Player SQL query number 2, (subquery). 



Result: 



ga.mej.ime 

46 

47 

48 

49 



unit_detected 

23 

■ 26 

29 

30 



Note: Current game_time now equal to 49. 
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Question: What is the average consumption of SAMs for the VINSON class 
of ships during the first 10 minutes of combat (once incoming cruise 
missiles have been detected) and the total number of successful 
intercepts of these missiles. 



SELECT {activejinit. type, count (activejunit. type) 

avg (dynjnfo. remaining), sum (c«gagc_^ara.target_status)} 

FROM (dynamic_information, engagement_data, active_units} 

WHERE active junit. type = 3 

AND acti ve_Mn/r.slot_number = dynamic -information. slot_number 
AND dynamic Jnformation.idtnfxfxcalion = SAM 

AND engagement jlata.gamcjime BETWEEN {engagement _data.gamQj.imt 
> = 32 and engagement jiata.game June < = 41) 

AND engagement _data. targe t_type = 5 

AND engagement jiata.larzytjlaXMS = 1 

AND engagement _<fara. uni t_name = active jinits.na.mc 



Result: 








active units 
type 


count 

(active junits) 
4 


avg(dyn info 
remaining) 

7 


sum(engage data 

target jtatus) 

11 



Note: It is assumed one knows the initial quantity of SAMs. 



Figure 4.14 Analyst SQL query sample, (JOIN). 



C. SUMMARY 

Chapter IV described methodology used to develop the Relational Data Base 
Design for the C2 workstation. This involved mapping the SDM to the relational 
DBMS, ORACLE, which NPS chose for their C2 workstation. The basic components 
of this design are relations, domains and attribute/domain correspondences, and 
interrelation constraints. The second major section of this chapter identified the current 
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system used by NOSC and how NPS's system would have to be constructed in a very 
similiar fashion. Two additional programs need to be developed. The first program is 
required to organize the data into six tables after it is extracted from the RESA 
wargame. The second program is needed to format the data in order to transmit it from 
the RESA wargame to the workstation via the ETHERNET. It was suggested that two 
sets of relational tables be implemented in the data base to permit the user to access 
the data during game execution. The first set would contain historical files for post 
game analysis, while the second set of tables would contain only those records from the 
most current game cycle. These tables were described in detail and used to construct 
several sample SQL queries to illustrate the types of information which can be 
extracted from the data base. 
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V. SUMMARY 



A. REVIEW OF THE PROBLEM 

This thesis supported the Naval Postgraduate School's (NPS) research into the 
development of a multimedia (text, voice, graphics), command and control (C2) 
workstation as a Decision Support System (DSS) to aid players of the Research, 
Evaluation, and System Analysis (RESA) facility. The problem involved interfacing the 
the C2 workstation to RESA to support post game analysis of the data and to permit 
players of the wargame to access real time data during game execution. This coincided 
with the Navy's overall problem of obtaining a workstation flexible enough to work 
with a wide variety of C2 systems and adaptable enough to meet the requirements of a 
diverse set of users. This meant using both voice and keyboard natural language 
interfaces on the workstation. 

With this understanding, the NPS chose the Sun microsystems' version of UNIX 
and ORACLE, a relational data base management system (DBMS) to function as the 
C2 workstation. The primary reason is that it supported a wide variety of multimedia 
functions including voice capability in the near future. NPS's long term goal is to use 
this workstation to provide players and analysts the capability of real time data 
extraction by using a voice, natural language interface to operate the system. As such, 
it was the goal of this thesis to define the boundaries of the problem and propose a 
data base design for the Sun workstation using data supplied by the Naval Ocean 
Systems Center (NOSC). 

B. CONCLUSIONS 

If it is assumed the RESA data is a good representation of data arriving from 
operational systems, then it is possible to make several conclusions in using the Sun 
workstation as a DSS. 

1. It is possible to define a data element dictionary for a military environment 
using the design of industry standard DBMS systems. 

2. A duplicate set of relational tables can be defined to store historical data and 
current data to allow a microsystem to operate as a DSS. 

3. The design of the DSS mav allow real time retrieval of aggregated data, in 
response "to user SQL or natural language queries, if the hardware and software 
operating speed is sufficient. 

4. It is possible to use a dedicated processor for off-line retrieval of data from an 
operational system. 
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5. A series of logical steps can be defined to develop a natural language interface 
to benefit infrequent users of the DSS. 



C. RECOMMENDATIONS 

After analyzing the data and conferring with people at NOSC, we recommend 
that the relational data base design be structured in accordance with the way data are 
extracted from the RESA wargame. It is already organized into logical tables and this 
will minimize the initial amount of work required to implement the system. Those 
changes in the design that did occur were in support of NPS's decision to use the C2 
workstation in the additional role as a DSS. Therefore, we recommend that two sets of 
relational tables be maintained in the DBMS on the workstation. The first set would 
contain all data extracted from the wargame scenario, while the second set would be an 
abbreviated file containing those records extracted from the last few game cycles. 

D. RECOMMENDATIONS FOR FURTHER STUDY 

The relational data base design is just the first step in the total research program 
in progress at NPS. Five additional programs were identified that need to be developed 
before this project can be completed. These include: 

1. DISK PIPE. EXEC program - is required to replace NOSC's 
TAPETPIPE.EXEC program. This is needed to clean up the data after it is 
extracted from the wargame and to organize the data into the six logical tables. 

2. An ETHERNET program module - this second program module is required to 
format the data in order to transmit it over the" ETHERNET to the Sun 
workstation. 

3. ORACLE interface module - once the Sun workstation receives the data it must 
be relormated again in terms of ORACLE so it can be written to the 
appropriate files. 

4. Menu driven module - the author recommends a menu driven interface be 
developed to assist the user in retrieving information from the data base. 
Although ORACLE uses SQL for this process the user must still be familiar 
with the data base organization for this method to be efFective. 

5. Natural language module - the ultimate goal of the svstem is to access the data 
via a natural language. It is due to the difFicultv that will be encountered in 
developing this module that the menu driven interface was proposed as an 
interim solution to access the data base. 

The first three programs should be considered as components of the larger project to 
interface the Sun workstation to the RESA facility. Once this stage is complete then 
the relational data base design can be implemented on the workstation using ORACLE 
as the DBMS. The next stage, developing a menu driven query program (as an interim 
solution until a natural language can be developed) is considerably larger in scope then 
the first three. As stated previously, menu driven interfaces require less memory and 
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appear well suited to command and control queries. The natural language program is 
the largest and most difficult task to be accomplished in the future. However, it offers 
the potential to reduce the learning curve for players using the system. It will aid the 
infrequent user in accessing data and in making queries that would be difficult to define 
in SQL. The payoff from this type of C2 system, with these capabilities, is a more 
robust approach to distributed command and control [Ref. 4: p. 1]. 

E. POTENTIAL PROBLEM AREAS 

There are several potential problems that may hinder the implementation of the 
proposed relational data base design and affect its efficiency when the workstation 
becomes operational. The biggest concern lies with the processing capability of the Sun 
workstation. Is it fast enough to handle the volume of data being transmitted from the 
RESA wargame within the designated one minute cycles? It is understood that the 
ETHERNET will ultimately control the maximum rate at which data is transmitted to 
the workstation, but will it be so busy accepting and receiving data that it will be too 
slow in performing any other function? The total quantity of data retrieved from one 
game lasting 7 5 minutes, can require anywhere from 55 to 100 Megabytes of disk 
storage. Even breaking down the data into one minute sections averaging just one 
Megabyte of information would still require a great deal of processing time. Multiply 
this number by the series of steps listed above and it becomes easy to understand how 
the system may not be unable to support and process such a large amount of data in a 
timely manner. 

A second issue, related to the first, is how "real time" the DSS will be in accessing 
the data. There may be so much data that it will be infeasible to update the current 
relational files even 7 game minute. It may be necessary to extend this time to two or 
three minute cycles. How effective would calculations be if they were made from data 
obtained only every 2 or 3 minutes, especially when RESA can lengthen the game cycle 
time at random. How then, would this affect the players using the workstation as a 
DSS? 

A final issue concerns the size of the overall data base collected for each 
wargame. Although the relational data base is a two dimensional flat file it is 
convenient to think of it as a three dimensional file with the third dimension being 
time. At game time = 1 the data base consists of single values for every data element 
in the program. At game time = 2 the data base grows to two values for every data 
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element. With the data base growing with each time cycle it is easy to see that this 
process will generate a very large and possibly unmanageable data set in a very short 
time. There are several possible approaches to this problem which take advantage of 
the fact that not all data changes each time and that not all data must be saved. This 
leads into the idea of adding temporal semantics into the DBMS. Significant savings in 
data base size and processing speed could be achieved just by processing data which 
has changed since the last game time. We feel this area is worth further study since it 
offers a potential solution for all three identified problems. 

These problems are going to be compounded as NPS expands the network by 
adding workstations. Not only will Sun stations be used but also existing HP 9020s. As 
such, the interface to establish correct protocol procedures between these two systems 
must also be addressed and developed. 

The final problem area which will affect the continued performance of the Sun 
workstation is NPS's ultimate goal to eventually tie this system into the Defense Data 
Network (DDN). This will allow direct interface with the RES A wargame located at 
NOSC. If this can be accomplished then these systems should be able to operate in a 
similiar environment from ship-to-ship or shore. 

In summary, there are a large number of questions that still need to be answered. 
This paper defined the project in concrete terms and proposed a relational data base 
design for the workstation based on work completed at NOSC. Problems were raised 
which need to be resolved before further work can continue while others will resolve 
themselves as the system becomes operational. Feedback provided by the players in the 
game will greatly enhance the effectiveness of the system as a DSS. If the system really 
is evolutionary, as all DSSs are supposed to be, then it will be able to meet the 
proposed changes in design and accommodate new systems such as the HP 9020 and 
the system at NOSC. 
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APPENDIX A 
SUN WORKSTATION 



This section describes the system selected by the Naval Postgraduate School to 
be used as the Command and Control Derision Support System to support RESA. 
There are two basic components; the Sun Workstation using Sun's version of UNIX 
operating system, and ORACLE, the Relational Data Base Management System 
(RDBMS). 

1. SYSTEM HARDWARE 

The Sun-3 product family is a group of 32-bit systems based on the Motorola 
MC 68020 CPU chip and the high-speed 32-bit VMEbus. It comes with a standard 2 
Megabytes of real memory expandable up to 16 Megabytes and can address up to 256 
Megabytes of virtual address space. The system includes a floating point accelerator, 
graphics processor board, and graphics buffer. The floating point accelerator runs up 
to four times faster than the MC6888 1 and gives two times the performance of a 
VAX780 using a floating point accelerator. The accelerator complies with the IEEE 
754 version 10 standard and supports both 32-bit and 64-bit floating-point operations. 
The graphics board can render 40,000 2D vectors per second or 25,000 3D vectors per 
second. The graphic buffer augments the graphics board and is intended for 
applications where 3D transformations and hidden surface remove is time critical. This 
combination can shade and remove hidden surfaces of 3D polygons faster than one 
million pixels per second or up to 35 million pixels per second for arbitrary polygons. 
Peripherals that can be attached to the system include SMD disks ranging in size from 
84 Megabytes to the 474 Megabyte 'Eagle' disk, a nine-track disk a one quarter inch 
cartridge tape, and SCSI disks and tapes. All systems communicate via the 
ETHERNET which is a 10 Megabit-per-second coaxial cable local area network 
facility. [Ref. 21: pp. 7-10] 

2. SYSTEM SOFTWARE 

The Sun Workstation runs an enhanced version of the 4.2BSD UNIX system 
derived from the University of California at Berkeley. The system provides support for 
interprocess communication and local area networking. The UNIX system is equipped 
with a host of software as a base level package. Supported languages are Pascal, C, 
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FORTRAN 77, and Assembler. There are utilities for performing statistical text 
processing and document preparation. In addition to the utilities package Sun has 
added User Interface package based on overlapping windows, and a graphics package 
to support the more common graphics standards. [Ref. 21: p 3] 

a. UNIX 

The operating system uses a hierarchical file system to group related files 
within a directory. A directory is simply a special case of file. Sun Microsystems have 
taken this idea one step further into a Network File System. This is a facility for 
sharing files in a heterogeneous environment of machines, operating systems and 
networks. Sharing is accomplished through a remote file system rather then reading or 
writing files in place. This avoids the problem of each node maintaining their own file 
system and thereby duplicating resources. 

There are two main shells on the Sun operating system. They are the C Shell 
in the command interpreter part of the 4.2 BSD operating system and the Bourne Shell 
which is the UNIX version 7 command interpreter. The two major external differences 
between the two shells is that the C Shell provides job control and history. Job control 
allows jobs to be run in the background or foreground. The history facility is used for 
reissuing previous commands. The number of commands possible is specified by the 
user. Major features that both shells provide to the user interface are 

1. Analysis of the command .line. Run the indicated command, passing the 
remainder of the command line as arguments to the command. Each command 
is run as a separate process. 

2. The shells can redirect the standard input, output, and error files as defined by 
the user. 

3. Can connect multiple processes together via a "pipeline." The standard output 
of one process is connected to the standard input of the next process in line. 

4. File name expansion. Metacharacters are provided to indicate aggregates of 
files. Matches can be made on single characters or strings of characters in a 
filename. 

5. Both shells provide user-defined search paths for finding commands. 

Both shells can be used as a programming language. The syntax of the C shell 
commands resembles the C programming language whereas the Bourne Shell resembles 
Algol-68. [Ref. 21: pp. 35-37] 

b. Window Utility 

Sun View is the Sun Visual/ Integrated Environment for Workstations. It has 
two components; a User Interface and a Sun Guide. The Sun Guide is a programming 
interface accessible via a collection of subroutine libraries. The user interface provides 
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multiple overlapping windows on the screen and each window runs independently of 
the other. It is a collection of software utilities that exploit the graphical capabilities of 
the Sun hardware. It uses a mouse as a pointing device as the primary mechanism for 
interacting with the tools. This avoids having to type in a response and having to wait 
for a response. Windows can be moved around the screen as needed and when closed 
becomes an "icon"; a small graphical object whose appearance sometimes suggests its 
function. Some of the features provided by the Sun Window System are a shelltool. 
iconedit. and mailtool. The shelltool provides a window'-based interface to the 
standard UNIX system command interpreters. Iconedit is used for designing icons and 
cursors. Mailtool interfaces to the standard mail reading facility. [Ref. 21: pp. 21-31] 
c. Mail Utility 

The Sun station supports tw r o types of mail routines; electronic mail and 
electronic message. Electronic mail is similiar to sending a telegram. It can be read, 
saved or edited. Electronic mail can be sent to the same machine, over a local network 
or remote network. An electronic message is like calling someone up on the phone. 
The person w'ho receives the message can reply to it while the user waits. There are 
four types of electronic messages; same machine, local network, broadcast, and system, 
which are messages the system sends to the user's console. [Ref. 23: pp. 3-4] 
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APPENDIX B 

ORACLE, A RELATIONAL DATA BASE MANAGEMENT SYSTEM 



ORACLE is relational database management system plus a complete set of 
integrated software tools for application development and decision support. These tools 
include an 

1. Application generator - this helps the user define an application by leading 
them through a simple question and answer dialogue. 

2. Report generator - allows the creation of both production and ad-hoc reports. 
It will automatically format any. SQL query into a report with columns and 
headings taken from the data dictionary. 

3. Color graphics - permits display of data in color, in the form of pie or bar 
charts, ana multi-line plots. 

4. Document preparation - lets the user interleave the results of multiple data base 
queries with text and graphics into a single formatted report or document. 

5. Integrated data dictionary - contains all the information about tables 
applications, reports, and graphs and is automatically updated by the system as 
new tables and applications are added to the data base. 

Data is displayed in a two-dimensional table and is accessed via a standard user 

interface, SQL (pronounced see-quel). SQL is an English-like language that can be 

used directly from the terminal or embedded in standard programming languages. SQL 

includes commands for 

1. Query - retrieving data from the data base. 

2. Data manipulation - inserting, updating, and deleting data. 

3. Data definition - adding new tables. 

4. Data control - preventing access to private data. 

SQL specifies operations in terms of what is to be done and not how to do it. It is a 
nonprocedural language. 

The basic SQL commands are SELECT, CREATE, and INSERT. SELECT 
retrieves rows of data from a table, CREATE defines a new table, and INSERT enters 
rows of data into a table. The SELECT command is used for data base retrieval. It is 
the most common operation done with ORACLE. The basic SELECT command has 
two parts, called clauses; 

1. The SELECT clause - lists the columns from the table to be retrieved. 

2. The FROM clause - names the tables where the columns are located. 
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The SELECT clause is always entered first and immediately followed by the FROM 
clause. These two commands would display all rows of information from the table. In 
order to select only specific rows of data, a WHERE clause must be added to the basic 
statements of SELECT and FROM. The WHERE command causes ORACLE to 
search the data in the table and retrieve only those rows that meet a search-condition. 
These conditions are varied by using AND, OR, BETWEEN and other clauses 
provided by ORACLE as clarifying statements. If more than one table of data needs to 
be queried for the information, then ORACLE will use a JOIN command to obtain the 
data. This command combines the data selected from multiple tables into a single 
table for display to the user. A sample query using SQL is depicted in Figure B.l. 



SELECT (name, job, salary) 

FROM (employees) 

WHERE job = technician 
AND salary > 2800: 

Resulting table: 

NAME JOB SALARY 

Harris technician 2975.00 

Terrill technician 2850.00 



Figure B.l SQL sample query. 

Another important feature of ORACLE'S SQL query language is its complete set 
of arithmetic and string functions. The arithmetic operators include adding, 
subtracting, multiplication, division, exponentiation, rounding, truncation, and absolute 
value. String functions include concatenation, translate, string length, substring, 
instring, upper case, lower case, and sound matching. These are only partial listings of 
the total capability. 

Information on ORACLE was provided by the ORACLE Corporation in their 
book ORACLE Overview and Introduction to SOL [Ref. 22]. 
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APPENDIX C 

RESA BLACKBOARD DATA 



The Naval Ocean Systems Center (NOSC) provided the data used in the data 
base design. After it is run through the TAPE_PIPE.EXEC program it is separated 
into six separate files corresponding to RESA tables. This section lists a portion of 
each of those files (for one game time slot only) and their associated fields. It also 



Data Item 



Field Name 



NF102 

PHENX 

BK133 

1 

65 



2 

1 

1 

1 

1 . 

65 

+ 0.7959 
+ 2.8293 
+ 0.S048 
+ 2.S339 
101817 
12 

101817 

0 

1 

21 



Missile Type 
Assigned Target 
Numbered Fifed 
Probability of Hit 
Status 
View 
In Use 
Detected 
Status of Target 
Type of Target 
Probabilitv Hit Target 
Latitude o'f Unit 
Longitude of Unit 
Latitude of Target 
Longitude of Target 
Pointer 

Length of Entry in Blackboard 
Base of Table 
Pointer Index 
Slot Number 
Game Time 



Figure C.l Engagement data. 

explains the relationship between each of the tables. The last six data items are not 
part of the data collected from the wargame. They are used for control purposes in the 
program and the names of these fields are identical in the rest of the tables, so they will 
not be repeated again. The two important control numbers are the slot number and 
the game time. The slot number uniquely identifies each record collected under the 
same game time. The game time distinguishes between like records within the same file. 
Information is collected from the RESA wargame once, sometimes more, during each 
game time or cycle (one minute of game play) for all the files. The values of data items 
within each record may have changed or records may have been added or deleted. 
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Data Item 


Field Name 


+ 0.0100 
+ 0.0100 
+ 0.0000 
+ 0.0000 
+ 0.0100 
21 
0 


Store Damage 
Hull Damage 
Sam Damage 
Top Side Damage 
Fuel Damage 
Equipment Identification 
Number Remaining 

Figure C.2 Data on ship dynamics. 


Data Item 


Field Name 


Petro 

2 

a 

7 

0 

0 

0 


Name 

Status 

View 

Tvpe 

Attack Index 
Hits 

Missile Hits 

Figure C.3 Platform unit data. 


Data Item 

+ 0.9279 
+ 2.7655 


Field Name 

True Latitude 
True Longitude 




Figure C.4 Position data. 



All the files are related through the slot number and the game time. The position 
file and platform file match up one-to-one by slot number and game time. This reveals 
the true position of each unit. The remote detection file and platform unit file match 
up one-to-one for game time but the detectee number in the remote detection file is 
matched to the slot number in the unit platform unit file. This identifies the target that 
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Data Item 


Field Name 


+ 0.8195 
+ 2.7799 
20 


Apparent Latitude 
Apparent Longitude 
Detectee 



Figure C.5 Remote detection data. 



Data Item 


Field Name 


69 


Time 


6 


Unit 


0 


Base 


0 


Fuel 


0 


Stores 


0 


Samsites 


1 


Sinking 


0 


Weapon Svstems 


0 


Next Index 


0 


Aircraft 


0 


Number Devices 


-> 


View 


4 


Report Status 


1 


Modified 


1 


Name Index 


0 


Speed 



Figure C.6 Unit damage data. 

is detected. In the unit damage file, the data item "unit" matches to the slot number in 
the platform unit data file under the same game time. This identifies the unit which 
received damage. The last relationship is between the data on ship dynamics and 
platform unit data. These files match one-to-one for slot number and game time to 
identify the appropriate dynamic information for the right unit. 
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APPENDIX D 

SEMANTIC DATA MODEL FOR THE DSS C2 WORKSTATION 



DYNAMICS JNFORMA TION 

description : contains dynamic data for ships, submarines, shore bases, 
and aircraft flights. 

member attributes : 

Name 

value class: UNIT_NAMES 

Store_damage 

value class: PERCENTAGE 

Huil_damage 

value class: PERCENTAGE 
Samjdamage 

value class: PERCENTAGE 

Top side _damage 

value class: PERCENTAGE 

Fuel_damage 

value class: PERCENTAGE 

Identification 

description: identifies equipment item attached to unit, 
for example, radar or missile type. 

value class: ITEM_NAME 
multivalued 

Remaining 

description: number of equipment items remaining under 
Identification due to operational damages or expenditures. 



value class: NUMBERJTEMS 
multivalued 



identifiers: 

Name 



Figure D.l SDM for the C2 workstation. 
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ACTIVE_UNITS 

description : Contains names, pointers, and other "quick reference" data 
for all active ships, shore bases, aircraft flights, ana cruise missiles. 

member attributes'. 

Name 

value class: UNIT_NAMES 
mandatory 

Status 

description : contains present condition of unit, for example, 
sinking or on station. 

value class : UNIT_STATUS 
mandatory 

View 

description : identifies character of unit, for example, hostile. 

value class: DISPOSITION 
mandatory 

Type 

description: identifies kind of unit, for example, submarine 
or cruise missile. 

value class: TYPEJJNIT 
mandatory 

Assigned jtarget jifjunit 

description : it indicates the target unit is attacking. 
value class: UNIT_NAMES 

Bombjiits 

description: contains number of bomb hits a unit received 
during a current game cycle. 

value class: NUMBER_EPU 
multivalued 

Missile_hits 

description: contains number of missile hits a unit received 
during a current game cycle. 

value class: NUMBER_EPU 
multivalued 

identifiers: 

Name 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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REMO TEJDETECTIONS 

description: contains detected tracks of active units. 
member attributes'. 

Apparent -latitude 

value class: POSITION_LATITUDE 
mandatory 

comment: must be in degrees. 

Apparent -longitude 

value class: POSITION_LONGITUDE 
mandatory 

comment: must be in degrees. 

Name _of_unit -detected 

value class: UNIT_NAMES 
identifiers: 

Name_of_unit_detected 

TRUE_POSlTION 

description: identifies ground true latitude and longitude of active 
units. 

member attributes: 

True platitude 

value class: POSITION, LATITUDE 
comment: must be in degrees. 

True Jongitude 

value class: POSITION_LONGITUDE 
comment: must be in degrees. 

Name_of_unit 

value class: UNIT_NAMES 
mandatory 

identifiers: 

Name 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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INFLICTED_DAMAGE 

description: contains damage information relative to ships, aircraft 
and various shore installations. 

member attributes: 

Time _of_damage 

value class’. MINUTES 
Damaged_unit 

value class: UNIT_NAMES 
multivalued 

Base 

description: indicates whether base did or did not receive damage. 
value class: INDICATOR 

Fuel 

description: indicates whether hull or fuel stores did or did not 
receive damage. 

value class: INDICATOR 

Stores 

description: indicates whether weapon stores did or did not 
receive damage. 

value class: INDICATOR 

Sam_ sites 

description: indicates whether SAM sites did or did not receive 
damage. 

value class: INDICATOR 

Sinking 

description: indicates whether a ship is or is not sinking. 
value class: INDICATOR 
Weapon jsys tern 

description: indicates whether weapon system did or did not 
receive damage. 

value class: INDICATOR 

Aircraft 

description: contains number of damaged parked aircraft. 
value class: PARKED AIRCRAFT 



Figure D.l SDM for the C2 workstation, (cont'd.) 



Number _devices 

description-, contains number of sensor devices that were 
damaged. 

value class : SENSORS_DAMAGE 

View 

description: identifies owner of damaged unit, example, hostile. 
value class'. DISPOSITION 

Report _status 

description: for example, report needed or report sent. 
value class : REPORTING 

Speed 

description: maximum speed of ship after damage. 
value class’. MAX_SPEED 
identifiers: 

Damage_unit 

ENGAGEMENT_DA TA 

description: contains force engagement data for ships, aircraft, and 
cruise missiles which are attacking opposing units. 

member attributes: 

Name _of -engaging _uni t 

value class: UNIT NAMES 

mandatory 

multivalued 

Type_of_missile Jired 

description: for example, sparrow, phenx. 

value class: TYPE_MISSILE 
multivalued 

Assigned- target _of_missile 

value class: TYPE_UNIT 

N umber _of jnissiles Jired • 

value class: NUMBER_FIRED 
multivalued 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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Probability _hi t 

description: contains probability of hitting target considering 
the range where missile was fired. 

value class : PERCENTAGE 

Status 

description: contains present condition of unit, for example, 
proceeding or on guide. 

value class : UNIT_STATUS 
mandatory 

View 

description: identifies character of attacking unit, example, 
friendly. 

value class: DISPOSITION 
mandatory 

Detected 

description: indicates unit has been detected. 
value class: YES 
Target_status 

description: indicates whether target was missed, hit and 
engagement is over, or engaging the target. 

value class: DAMAGED 
multivalued 

Target jtype 

description: identifies kind of unit being attacked, for example, 
ship. 

value class: TYPEJJNIT 
mandatory 

Probabili tyjiitjtarget 

description: contains probability that missile will hit target 
given the target's electronic counter measure capabilities. 

value class: PERCENTAGE 

Unit Jatitude 

value class : POSITION_LATITUDE 
comment: must be in degrees. 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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Unit Jongitude 

value class: POSITION_LONGITUDE 
comment : must be in degrees. 

Target _latitude 

value class : POSITION_LATITUDE 
comment : must be in degrees. 

Target Jongitude 

value class: POSITION_LONGITUDE 
comment : must be in degrees, 
identifiers: 

Name_of_engaging_unit 
UNIT _N AMES 

description: contains names of all ships, subs, aircraft, cruise 
missiles and shore stations. 

interclass connection: subclass of STRINGS where leneth is less than 
eight characters. 

UNIT _S TAT US 

description: contains present condition of each active unit, for 
example, being deleted, proceeding or recovery. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than 10. 

TYPE_UNIT 

description: identifies kind of unit, for example, surface or shore 
base. 

interclass connection: subclass of STRINGS where format is a 
positive integer less than 11. 

DISPOSITION 

description: identifies whether unit is neutral, friendly, hostile, 
or unknown. 

interclass connection: subclass of STRINGS where format is a 
positive integer less than 11. 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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NUMBERJEP U 

description: identifies number of explosive power units (EPU) 
received by a unit. 

interclass connection: subclass of STRINGS where format is 
non-negative less than 201. 

MINUTES 

description: identifies game time when unit was damaged. 

interclass connection: subclass of STRINGS where format is 
non- negative integer less 2401. 

INDICATOR 

description: statement indicates whether unit did or did not receive 
any damage. 

interclass connection: subclass of STRINGS where format is 0 or 1. 
PARKED _AIRCRAFT 

description: identifies number of parked aircraft that were damaged. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than 1001. 

SENSORS_DAMAGED 

description: indicates number of damaged sensor devices. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than 25. 

REPORTING 

description: indicates reported status on damaged units, for 
example, report received. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than eight. 

MAXJPEED 

description: indicates maximum speed of ship, in knots, after being 
damaged. 

interclass connection: subclass of STRINGS where format is 
non- negative integer less than 61. 

PERCENTAGE 

interclass connection: subclass of STRINGS where format is a real 
number between or equal to 0 and 1. 



Figure D.l SDM for the C2 workstation, (cont'd.) 
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ITEM_NAME 

description : identifies name of equipment item attached to unit. 

interclass connection : subclass of STRINGS where length is 
less than 10 characters. 

NUMBER JTEMS 

description: contains amount of equipment items still operating 
after a unit is damaged. 

interclass connection : subclass of STRINGS where format is 
non-negative integer less than 5000. 

TYPEjMISSILE 

interclass connection : subclass of STRINGS where length is less than 
eight characters. 

NUMBER_FIRED 

description : contains number of missiles fired at a target from one 
unit. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than 10. 

YES 

description: indicates unit has been detected. 

interclass connection: subclass of STRINGS where format is 0 or 1. 
DAMAGED 

description: indicates if target was missed by a missile, 
hit by a missile and engagement over, or engaging target. 

interclass connection: subclass of STRINGS where format is 
non-negative integer less than 5. 

POSITION_LA TITUDE 

description : indicates latitude of unit in degrees. 

interclass connection: subclass of STRINGS where format is number 
LLMMSS and X is a character. 

POSITION_LONGI TUDE 

description: indicates longitude of unit in degrees. 

interclass connection: subclass of STRINGS where format is number 
LLLMMSS and X is a character. 



Figure D. 1 SDM for the C2 workstation, (cont'd.) 
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